home *** CD-ROM | disk | FTP | other *** search
/ The Arsenal Files 1 / The Arsenal Files (Arsenal Computer).ISO / bbs / tm0301.txt < prev    next >
Encoding:
Text File  |  1994-01-23  |  9.5 KB  |  220 lines
  1. SEA Technical Memorandum #0301, Technical Aspects of Implementing GroupMail
  2. Last updated: October 5, 1989
  3. Copyright 1988,89 by System Enhancement Associates, Inc.
  4.  
  5.  
  6.  
  7.                              Technical Aspects
  8.                                      of
  9.                            Implementing GroupMail
  10.  
  11.  
  12. In the documentation for the GROUP conferencing system, we talked about how 
  13. to use GROUP to interface other types of systems into GroupMail.  Our 
  14. example showed how to do it with TBBS, but there are many other types of 
  15. systems that are in the same boat.  
  16.  
  17. The best way to do it, of course, is for GroupMail handling to be 
  18. integrated into the system directly, using that system's own native message 
  19. base format.  
  20.  
  21. For any given system in any given conference, the system can be in any one 
  22. of three positions: a leaf, a middle star, or the top star.  Also, group 
  23. mail messages can arrive on the system in any one of three ways: by being 
  24. entered locally, or by network mail, or inside of a GroupMail archive.  The 
  25. proper action to take for any given message depends on these factors as 
  26. follows: 
  27.  
  28.                   entered          via netmail        via GroupMail
  29.                 +----------------+------------------+--------------------+
  30.     leaf        | send to uplink | send to uplink   | unpack to msg area |
  31.                 +----------------+------------------+--------------------+
  32.     middle star | send to uplink | send to uplink   | copy and unpack    |
  33.                 +----------------+------------------+--------------------+
  34.     top star    | pack           | toss to msg area | can't happen       |
  35.                 +----------------+------------------+--------------------+
  36.  
  37. We'll explain those actions in a bit more detail: 
  38.  
  39.     Send to uplink;  The destination address in the message header should 
  40.     be changed to that of the uplink.  The origin address should NOT be 
  41.     altered.  
  42.  
  43.     Unpack to message area;  The received GroupMail archive should be 
  44.     unpacked, and all of the messages in it should be placed in the 
  45.     appropriate message base.  The "name" portion of the archive filename 
  46.     identifies which group the messages belong to.  The archive should be 
  47.     deleted once it has been unpacked.  
  48.  
  49.     Copy and unpack;  This is the same as unpacking to a message area, 
  50.     except that the GroupMail archive is not deleted.  Instead, it is moved 
  51.     to a "holding area" where other systems can request it.  Presumably 
  52.     some regular process deletes archives in the holding area after they 
  53.     have been around long enough (however long that is).  
  54.  
  55.     Pack;  The message should be added to a GroupMail packet, which is then 
  56.     archived into a GroupMail archive.  The archive should be placed in a 
  57.     "holding area" where other systems can request it.  Presumably a 
  58.     regular process cleans out the holding area, as with a midstar's "copy 
  59.     and pack" process.  Due to the fact that GroupMail archive names "wrap" 
  60.     every month, a topstar should not retain GroupMail archives for longer 
  61.     than 28 days.  
  62.  
  63.     Toss to message area;  The message should be moved into the appropriate 
  64.     message base.  
  65.  
  66.     Can't happen;  The top star of any given conference does not request 
  67.     GroupMail archives for that conference from other systems.  Instead, 
  68.     GroupMail messages are sent to him via network mail.  Thus, the top 
  69.     star never receives any GroupMail archives for his own conference.  So 
  70.     of course this will happen eventually.  
  71.  
  72.  
  73. Details, details.
  74.  
  75.  
  76. Group names may be up to eight characters, including A to Z, 0 to 9, and 
  77. underscore.  GROUP massages any group name it is given to match this, by 
  78. truncating at eight characters and changing anything that is not a letter 
  79. or a digit into an underscore.  Thus, "GZORNIBLATZ" becomes "GZORNIBL" and 
  80. "TK!43*" becomes "TK_43_".  The group archive extension is the base 36 
  81. minute of the month.  For those who insist that we send code, it can be 
  82. calculated easily like so: 
  83.  
  84.     static char *chset = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"
  85.     unsigned x;
  86.     char ext[4];
  87.  
  88.     x = minute + 60 * (hour + 24 * (day-1));
  89.  
  90.     ext[3] = 0;
  91.     ext[2] = chset[x%36]; x /= 36;
  92.     ext[1] = chset[x%36]; x /= 36;
  93.     ext[0] = chset[x%36];
  94.  
  95.  
  96. Group archives contain FidoNet standard "type 2" packets.  The packets are 
  97. named as follows:
  98.  
  99.     ddhhmmss.PKT
  100.  
  101. Where "dd" is the day of the month that the packet was created, and 
  102. "hhmmss" is the time of day.  However, almost anything ending in ".PKT" 
  103. will do.  
  104.  
  105.  
  106. GroupMail messages that are moving "up" the chain to the top star contain a 
  107. group designator.  This is a line in the text of the message of the form: 
  108.  
  109.     ^aGROUP: <group>
  110.  
  111. where "^a" is an ASCII "start of header" (control A, decimal value 1), and 
  112. "<group>" is the group name.  This field may be anywhere in the message 
  113. text.  
  114.  
  115.  
  116.  
  117. Ping/Pong:
  118.  
  119. GroupMail incorporates automatic topology mapping in the form of "Ping!" 
  120. and "Pong!" messages.  From time to time a topstar may request topology 
  121. data for his conference by issuing a "Ping!" message.  This is simply a 
  122. message in the conference where the message subject is the literal string 
  123. "Ping!", where case is important.  The text of the message is irrelevant to 
  124. the ping/pong process, but is usually used to distribute a "topology map" 
  125. giving the results of the previous ping.  
  126.  
  127. To prevent false pings, the topstar should never import a message with a 
  128. subject of "Ping!".  In the case of GROUP, messages received by the topstar 
  129. with a subject of "Ping!" have the subject field altered to read "ping!" 
  130. (i.e. the uppercase 'P' is turned into a lowercase 'p').
  131.  
  132. When a midstar or leaf node encounters a downward-bound "Ping!" message 
  133. (i.e. when unpacking a GroupMail archive) it should respond by generating a 
  134. "Pong!" message.  This is simply a message addressed to the uplink with the 
  135. proper ^aGROUP: identifier, a subject of "Pong!", and one line of pong data 
  136. (see below).  
  137.  
  138. When a midstar encounters an upward-bound "Pong!" message (i.e. when 
  139. scanning the network mail area) it should readress it to the uplink as with 
  140. normal upward-bound GroupMail, and it should add one line of pong data (see 
  141. below) to the END of the message text.  Pong data added by a midstar should 
  142. ALWAYS go at the end, as order is significant in determining the actual 
  143. conference topology.
  144.  
  145. When a topstar encounters a "Pong!" message it should extract whatever data 
  146. is desired and then discard the message.  Pong messages should NEVER be 
  147. posted in the GroupMail conference, as they are not designed to be directly 
  148. meaningful to conference participants.  
  149.  
  150. Pong data added by a leaf or midstar always takes the same form.  One pong 
  151. data entry consists of one line of message text with the format:
  152.  
  153.     PONG <addr> <uplink> <keep> <progid> <eol>
  154.  
  155. where:
  156.  
  157.     PONG      is the literal string "PONG"
  158.  
  159.     <addr>    is the network address of the system that generated this 
  160.               entry
  161.  
  162.     <uplink>  is the network address of the uplink for the system that 
  163.               generated this entry
  164.  
  165.     <keep>    is the number of days that this system retains this 
  166.               conference (if a midstar), or zero (if a leaf node)
  167.  
  168.     <progid>  is the name of the program used to process GroupMail at this 
  169.               location 
  170.  
  171.     <eol>     is a literal end of line (carriage return/linefeed)
  172.  
  173. Each of these fields is a single word.  Spaces are not allowed because they 
  174. are used to separate fields.
  175.  
  176.  
  177. For example, the text of a typical pong message might look like this:
  178.  
  179.     ^aGROUP: BLATZ
  180.     PONG 520/911 520/901 0 GMAIL_2.00
  181.     PONG 520/901 520/1015 5 GMM
  182.     PONG 520/1015 520/583 3 GROUP_2.1
  183.  
  184.  
  185. The network addresses given in <addr> and <uplink> are unevaluated text 
  186. strings, and may be in any format.  For example, "107/542", "1:107/542.6", 
  187. "1:107/542@FIDONET", and even "1-201-472-8065" are all legal.
  188.  
  189.  
  190.  
  191. Implementation notes:
  192.  
  193. GROUP creates and maintains a "target file" for every conference.  This is 
  194. a file placed in the group directory where the filename matches the group 
  195. name, and the extension is an exclamation point.  For example, the target 
  196. file for the BLATZ conference would be named "BLATZ.!".  This file is zero 
  197. bytes in length, and thus does not occupy any disk space.  GROUP maintains 
  198. the MS-DOS date/time stamp on the target file to match that of the newest 
  199. group mail archive that has been unpacked for that conference.  Thus, 
  200. requesting an update of "BLATZ.*" will receive only those GroupMail 
  201. archives that are newer than the target file, and hence newer than the 
  202. latest archive received.  
  203.  
  204.  
  205. GROUP also creates and maintains several files that act as "high water 
  206. marks".  These are named "GROUP.!" and are placed in the message 
  207. directories.  They are marked as hidden system files so that they do not 
  208. get mangled by other processes.  GROUP only examines messages that are 
  209. newer than the associated high water mark, and then stamps the high water 
  210. mark to be as new as the newest message examined.  If the "/S" (for "slow 
  211. scan") option is specified, then GROUP will examine all messages.  
  212.  
  213. When a GroupMail archive is unpacked, GROUP sets the date/time stamp of the 
  214. messages that are imported to match that of the high water mark.  Also, 
  215. each message is marked as "sent", so that they do not get scanned out 
  216. again.  
  217.  
  218. The top star receives messages by network mail instead of as GroupMail 
  219. archives.  In this case the messages are NOT marked "sent".  
  220.